Subject: Proposal for APPN Class of Service

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Wed, 2 Aug 95 17:43:50 EDT

I would like to make a few comments in response to Jim Cobban's note.

>Gary is right to point out that low delay circuits will generally have
>higher tariffs/costs than high delay circuits.  Therefore his suggestion
>to reflect the network delay characteristic in the Cost/Byte column as
>well as in the network delay column is reasonable.
>
>However Gary's Delay row does not match the real behavior of a network.
>Most particularly no amount of priority is going to make a packet cover
>a satellite hop in 36 milliseconds (the meaning of Delay=0x81).

I agree.

>It is also important to recognize that in the real world priority does
>NOT typically have much effect to reduce average delay.  Priority only
>affects average delay on congested trunks, and few networks are designed
>so that they are normally congested.

I agree that networks aren't designed to be normally congested.  To me,
the term congestion implies overutilization resulting in very poor
performance.  However, one goal of APPN is to allow high utilization
of links while providing good service for interactive traffic.

>What high priority typically DOES buy is not LOW delay, but rather
>CONSISTENT delay.  Note that delay variance IS one of the explicit QoS
>characteristics in ATM.  However it is NOT one of the TG characteristics
>recognized by APPN.  The reason that a network administrator prefers a
>high priority VC for interactive traffic is because of the
>predictability of response time,  which is a consequence of the low
>variance in network delay of a high priority virtual circuit.

Low delay variance (or jitter) is important for voice or video traffic.
It is also true, as Dave Finnie points out, that a large variance in
delay is quite annoying for interactive applications.  However, for
interactive traffic, I think the important quality is low delay even
with high utilization.  The definition of the propagation delay TG
characteristic in the APPN Architecture Reference is not very specific;
it is not specified as either average delay, maximum delay, 3 sigma
delay, etc.  I would suggest that we think of the propagation delay TG
characteristic as being the delay on a highly utilized (but not
overutilized) circuit.  With this definition for delay, I believe the
queueing delay on a low-priority circuit is a significant factor.  My
information is that link utilization will be high in ATM networks and
that the queueing delay for a best-effort ATM VC will be significant.

>That is why the Delay characteristic line in the above must be:
>
>            lowpri/sat  lowpri/delsen   hipri/sat   hipri/delsen
>Delay           99            91            99          91
>

My original delay suggestion wasn't realistic.  I'll suggest some more
realistic values below, but the values for a given network need to be
based on the services it offers.

            lowpri/sat  lowpri/delsen   hipri/sat   hipri/delsen
Delay           9A           8D            97           7A

>As far as the COS table goes, Gary is right to point out that the
>customer does not really want to prefer high cost circuits for
>interactive traffic.  However cost per byte is much less significant
>with interactive traffic than with batch.  If there were some other way
>to prefer high priority virtual circuits than through the Cost/Byte row,
>then I would propose that the interactive COS entries should have
>cost/byte ranges of 0 to 255.  However, there does not appear to be any
>current TG characteristic which is demonstrably better on a high
>priority VC than a low priority VC.  Therefore I stand by my contention
>that the COS entries for interactive and system management should be
>modified to request high cost/byte VCs when looking at TGs with packet
>delay or worse.

Did you consider how to represent a PVC with a priority and/or delay
sensitive service?  I have been thinking that PVCs like leased lines
would have a cost/byte of 0.  One concern I have with this approach is
that it could result in favoring an SVC over a PVC with equivalent delay.

Gary Dudley
IBM APPN Architecture Team

---

From: "jim (j.) cobban" <[email-masked]>
Date: Thu, 3 Aug 1995 10:56:00 -0400

>that it could result in favoring an SVC over a PVC with equivalent delay.

At least in X.25, whether a circuit is a PVC or an SVC does not normally
affect the tariff.  You still have to pay for all of the packets that you
send.  Cost per byte is therefore still applicable.

In the case of Frame-Relay PVC, which generally has similar delay
characteristics to X.25, there is generally a flat tariff based upon
committed information rate (CIR) and priority.  That will probably be the
case for ATM PVC as well.  In the case of FR and ATM SVC this will probably
be a time sensitive tariff.  Therefore the first approach might seem to be to
have a zero cost/byte for these services.  However since there is still a
higher cost for high-priority virtual circuits, and for circuits with a
higher CIR, it seems reasonable to me to treat these services as if they did
have a cost/byte which is estimated by multiplying the CIR by the lifetime of
the VC and dividing that into the tariff.  That way cost/byte can still be
used to discourage use of high-priority VCs by batch traffic.

I stand by my contention that high-priority does not buy significantly lower
delay than low-priority.

---

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 9 Aug 1995 17:58:00 -0400

>            lowpri/sat  lowpri/delsen   hipri/sat   hipri/delsen

These values are still unrealistic:

   lowpri/sat		9A = .327 seconds (OK)
   lowpri/delsen	8D = .106 seconds (Maybe OK for ATM/Frame Relay)
   hipri/sat		97 = .245 seconds (signal is still 5000 km up on
					   way down from satellite)
   hipri/delsen		7A = .020 seconds (in your dreams)

More importantly implementing these values requires much more massive
modifications of all of the COS tables in the world than my proposal.

Perhaps, as Gary points out, APPN is designed to run dedicated
links to high utilization, but that is NOT what we are dealing with here.  We
are dealing with the engineering practices of public switched data
networks.  These practices are to never engineer a trunk for more than 80%
sustained load.  The equipment which most of these networks use is designed
on those assumptions.  All of Nortel's engineering measurements are performed
with trunks loaded to less than 80%.  Under those circumstances there is no
significant difference in mean delay between high and low priority traffic.

If my original proposal to calculate the weight based upon a preference for
high cost per byte routes is unacceptable to the group, then I propose that a
new column, delay variability/delay variation/jitter, be added, with the same
units and representation as the existing delay column.  Unfortunately that is
a massive change not only to the COS tables themselves, but to all of the
node implementations as well.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |